网络层(Network Layer)

• transport segment from sending to receiving host
• on sending side encapsulates segments into datagrams
• on receiving side, delivers segments to transport layer
• network layer protocols in every host, router
• router examines header fields in all IP datagrams passing through it

network-layer functions:

• forwarding: move packets from router’s input to appropriate router output
• routing: determine route taken by packets from source to destination(routing algorithms)

analogy: taking a trip

• forwarding: process of getting through single interchange
• routing: process of planning trip from source to destination

Data plane

• local, per-router function
• determines how datagram arriving on router input port is forwarded to router output port
• forwarding function

Control plane

• network-wide logic
• determines how datagram is routed among routers along end-end path from source host to destination host
• two control-plane approaches:
• • traditional routing algorithms: implemented in routers
• • software-defined networking (SDN): implemented in (remote) servers

Per-router control plane

Individual routing algorithm components in each and every router interact in the control plane

Logically centralized control plane

Q: What service model for “channel” transporting datagrams from sender to receiver?

example services for individual datagrams:

• guaranteed delivery
• guaranteed delivery with less than 40 msec delay

example services for a flow of datagrams:

• in-order datagram delivery
• guaranteed minimum bandwidth to flow
• restrictions on changes in inter-packet spacing

Data plane

Router

Router architecture overview

high-level view of generic router architecture:

Input port functions

decentralized switching:

• using header field values, lookup output port using forwarding table in input port memory (“match plus action”)
• goal: complete input port processing at ‘line speed’
• queuing: if datagrams arrive faster than forwarding rate into switch fabric
• destination-based forwarding: forward based only on destination IP address (traditional)
• generalized forwarding: forward based on any set of header field values

Longest prefix matching

when looking for forwarding table entry for given destination address, use longest address prefix that matches destination address.

• we’ll see why longest prefix matching is used shortly, when we study addressing

• longest prefix matching: often performed using ternary content addressable memories (TCAMs)

• • content addressable: present address to TCAM: retrieve address in one clock cycle, regardless of table size
• • Cisco Catalyst: can up ~1M routing table entries in TCAM

Switching fabrics

transfer packet from input buffer to appropriate output buffer

• switching rate: rate at which packets can be transfer from inputs to outputs
• • often measured as multiple of input/output line rate
• • N inputs: switching rate N times line rate desirable

three types of switching fabrics

memory

first generation routers:

• traditional computers with switching under direct control of CPU
• packet copied to system’s memory
• speed limited by memory bandwidth (2 bus crossings per datagram)

bus

datagram from input port memory to output port memory via a shared bus

• bus contention: switching speed limited by bus bandwidth
• 32 Gbps bus, Cisco 5600: sufficient speed for access and enterprise routers

interconnection network

• overcome bus bandwidth limitations
• banyan networks, crossbar, other interconnection nets initially developed to connect processors in multiprocessor
• advanced design: fragmenting datagram into fixed length cells, switch cells through the fabric.
• Cisco 12000: switches 60 Gbps through the interconnection network

Input port queuing

fabric slower than input ports combined -> queueing may occur at input queues

• queueing delay and loss due to input buffer overflow!
• Head-of-the-Line (HOL) blocking: queued datagram at front of queue prevents others in queue from moving forward

Output ports(This slide in HUGELY important!)

• buffering required when datagrams arrive from fabric faster than the transmission rate
• • Datagram (packets) can be lost due to congestion, lack of buffers

• scheduling discipline chooses among queued datagrams for transmission

• • Priority scheduling – who gets best performance, network neutrality

Output port queueing

• buffering when arrival rate via switch exceeds output line speed
• queueing (delay) and loss due to output port buffer overflow!

How much buffering

RFC 3439 rule of thumb: average buffering equal to “typical” RTT (say 250 msec) times link capacity C

• e.g., C = 10 Gpbs link: 2.5 Gbit buffer

recent recommendation: with N flows, buffering equal to
$$\frac{RTT * C}{\sqrt{N}}$$

Scheduling mechanisms

scheduling: choose next packet to send on link

• FIFO (first in first out) scheduling: send in order of arrival to queue
• • real-world example?
• • discard policy: if packet arrives to full queue: who to discard?
• • • tail drop: drop arriving packet
• • • priority: drop/remove on priority basis
• • • random: drop/remove randomly

Scheduling policies

priority scheduling: send highest priority queued packet

• multiple classes, with different priorities
• • class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.
• • real world example?

Round Robin (RR) scheduling:

• multiple classes
• cyclically scan class queues, sending one complete packet from each class (if available)
• real world example?

Weighted Fair Queuing (WFQ):

• generalized Round Robin
• each class gets weighted amount of service in each cycle
• real-world example?

IP: Internet Protocol

host, router network layer functions:

IP datagram format

IP fragmentation, reassembly

• network links have MTU (max.transfer size) - largest possible link-level frame
• • different link types, different MTUs

• large IP datagram divided (“fragmented”) within net

• • one datagram becomes several datagrams
• • “reassembled” only at final destination
• • IP header bits used to identify, order related fragments

example:

• 4000 byte datagram
• MTU = 1500 bytes

IP addressing

IP address: 32-bit identifier for host, router interface

interface: connection between host/router and physical link

• router’s typically have multiple interfaces
• host typically has one or two interfaces (e.g., wired Ethernet, wireless 802.11)

IP addresses associated with each interface

Q: how are interfaces actually connected?

• A: we’ll learn about that in chapter 5, 6.
• A: wired Ethernet interfaces connected by Ethernet switches

• A: wireless WiFi interfaces connected by WiFi base station

• For now: don’t need to worry about how one interface is connected to another (with no intervening router)

Subnets

• IP address:
• • subnet part - high order bits
• • host part - low order bits
• what’s a subnet?
• • device interfaces with same subnet part of IP address
• • can physically reach each other without intervening router
• • to determine the subnets, detach each interface from its host or router, creating islands of isolated networks
• • each isolated network is called a subnet

CIDR

CIDR: Classless InterDomain Routing

• subnet portion of address of arbitrary length
• address format: a.b.c.d/x, where x is # bits in subnet portion of address

Q: How does a host get IP address?

• hard-coded by system admin in a file
• • Windows: control-panel->network->configuration->tcp/ip->properties
• • UNIX: /etc/rc.config
• DHCP: Dynamic Host Configuration Protocol
• • dynamically get address from as server
• • “plug-and-play”

DHCP: Dynamic Host Configuration Protocol

goal: allow host to dynamically obtain its IP address from network server when it joins network

• can renew its lease on address in use
• allows reuse of addresses (only hold address while connected/“on”)
• support for mobile users who want to join network (more shortly)

DHCP overview:

• host broadcasts “DHCP discover” msg [optional]
• DHCP server responds with “DHCP offer” msg [optional]
• host requests IP address: “DHCP request” msg
• DHCP server sends address: “DHCP ack” msg

DHCP can return more than just allocated IP address on subnet:

• address of first-hop router for client
• name and IP address of DNS sever
• network mask (indicating network versus host portion of address)

Hierarchical addressing: route aggregation

Q: how does network get subnet part of IP addr?

• A: gets allocated portion of its provider ISP’s address space

hierarchical addressing allows efficient advertisement of routing
information:

ISPs-R-Us has a more specific route to Organization 1

Q: how does an ISP get block of addresses?

• A: ICANN: Internet Corporation for Assigned Names and Numbers http://www.icann.org/
• • allocates addresses
• • manages DNS
• • assigns domain names, resolves disputes

NAT: network address translation

motivation: local network uses just one IP address as far as outside world is concerned:

• range of addresses not needed from ISP: just one IP address for all devices
• can change addresses of devices in local network without notifying outside world
• can change ISP without changing addresses of devices in local network
• devices inside local net not explicitly addressable, visible by outside world (a security plus)

implementation: NAT router

• outgoing datagrams: replace(source IP address, port #) of every outgoing datagram to (NAT IP address, new port #)
• • remote clients/servers will respond using (NAT IP address, new port #) as destination addr
• remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair
• incoming datagrams: replace (NAT IP address, new port #) in dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table

• 16-bit port-number field:
• • 60,000 simultaneous connections with a single LAN-side address!
• NAT is controversial:
• • routers should only process up to layer 3
• • address shortage should be solved by IPv6
• • violates end-to-end argument
• • NAT possibility must be taken into account by app designers, e.g., P2P applications
• • NAT traversal: what if client wants to connect to server behind NAT?

IPv6

initial motivation: 32-bit address space soon to be completely allocated.

additional motivation:

• header format helps speed processing/forwarding
• header changes to facilitate QoS

IPv6 datagram format:

• fixed-length 40 byte header
• no fragmentation allowed

• priority: identify priority among datagrams in flow
• flow Label: identify datagrams in same “flow.” (concept of“flow” not well defined).
• next header: identify upper layer protocol for data

Other changes from IPv4

• checksum: removed entirely to reduce processing time at each hop
• options: allowed, but outside of header, indicated by “Next Header” field
• ICMPv6: new version of ICMP
• • additional message types, e.g. “Packet Too Big”
• • multicast group management functions

Transition from IPv4 to IPv6

• not all routers can be upgraded simultaneously
• no “flag days”
• how will network operate with mixed IPv4 and IPv6 routers?

tunneling: IPv6 datagram carried as payload in IPv4 datagram among IPv4 routers

IPv6 adoption

• Google: 8% of clients access services via IPv6

• NIST: 1/3 of all US government domains are IPv6 capable

• Long (long!) time for deployment, use

• • 20 years and counting!
• • think of application-level changes in last 20 years: WWW, Facebook, streaming media, Skype, …

Generalized Forwarding and SDN

Each router contains a flow table that is computed and distributed by a logically centralized routing controller

OpenFlow data plane abstraction

• flow: defined by header fields
• generalized forwarding: simple packet-handling rules
• • Pattern: match values in packet header fields
• • Actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller
• • Priority: disambiguate overlapping patterns
• • Counters: #bytes and #packets

Flow table in a router (computed and distributed by controller) define router’s match+action rules

1. src=1.2.., dest=3.4.5.* -> drop
2. src = ..., dest=3.4.. -> forward(2)
3. src=10.1.2.3, dest=... -> send to controller

Flow Table Entries

OpenFlow abstraction

match+action: unifies different kinds of devices

Router

• match: longest destination IP prefix
• action: forward out a link

Switch

• match: destination MAC address
• action: forward or flood

Firewall

• match: IP addresses and TCP/UDP port numbers
• action: permit or deny

NAT

• match: IP address and port
• action: rewrite address and port

Example: datagrams from hosts h5 and h6 should be sent to h3 or h4, via s1 and from there to s2

Control plane

Routing protocols

Routing protocol goal: determine “good” paths (equivalently, routes), from sending hosts to receiving host, through network of routers

• path: sequence of routers packets will traverse in going from given initial source host to given final destination host
• “good”: least “cost”, “fastest”, “least congested”
• routing: a “top-10” networking challenge!

Graph abstraction of the network

graph: G = (N,E)

N = set of routers = { u, v, w, x, y, z }

E = set of links ={ (u,v), (u,x), (v,x), (v,w), (x,w), (x,y), (w,y), (w,z), (y,z) }

aside: graph abstraction is useful in other network contexts, e.g.,
P2P, where N is set of peers and E is set of TCP connections

costs

c(x,x’) = cost of link (x,x’); e.g., c(w,z) = 5

cost could always be 1, or inversely related to bandwidth, or inversely related to congestion

• key question: what is the least-cost path between u and z ?
• routing algorithm: algorithm that finds that least cost path

Routing algorithm classification

Q: global or decentralized information?

• global:
• • all routers have complete topology, link cost info
• • “link state” algorithms
• decentralized:
• • router knows physically-connected neighbors, link costs to neighbors
• • iterative process of computation, exchange of info with neighbors
• • “distance vector” algorithms

Q: static or dynamic?

• static:
• • routes change slowly over time
• dynamic:
• • routes change more quickly
• • • periodic update
• • • in response to link cost changes

link state

A link-state routing algorithm

Dijkstra’s algorithm

• net topology, link costs known to all nodes
• • accomplished via “link state broadcast”
• • all nodes have same info
• computes least cost paths from one node (‘source”) to all other nodes
• • gives forwarding table for that node

• iterative: after k iterations, know least cost path to k dest.’s

• notation:

• c(x,y): link cost from node x to y; = ∞ if not direct neighbors
• D(v): current value of cost of path from source to dest. v
• p(v): predecessor node along path from source to v
• N’: set of nodes whose least cost path definitively known

1  Initialization: 
2    N' = {u} 
3    for all nodes v 
4      if v adjacent to u 
5          then D(v) = c(u,v) 
6      else D(v) = ∞ 
7 
8   Loop 
9     find w not in N' such that D(w) is a minimum 
10    add w to N' 
11    update D(v) for all v adjacent to w and not in N' : 
12       D(v) = min( D(v), D(w) + c(w,v) ) 
13    /* new cost to v is either old cost to v or known 
14     shortest path cost to w plus cost from w to v */ 
15  until all nodes in N'

Dijkstra’s algorithm example

• notes:
• construct shortest path tree by tracing predecessor nodes
• ties can exist (can be broken arbitrarily)

Dijkstra’s algorithm discussion

algorithm complexity: n nodes

• each iteration: need to check all nodes, w, not in N
• n(n+1)/2 comparisons: O(n2)
• more efficient implementations possible: O(nlogn)

oscillations possible:

• e.g., support link cost equals amount of carried traffic:

  

Distance vector algorithm

Bellman-Ford equation (dynamic programming)

• min taken over all neighbors v of x
• c(x,v): cost to neighbor v
• dv(y): cost from neighbor v to destination y

let
   dx(y) := cost of least-cost path from x to y
then
   dx(y) = min {c(x,v) + dv(y)}

Bellman-Ford example

node achieving minimum is next hop in shortest path, used in forwarding table

• Dx(y) = estimate of least cost from x to y
• • x maintains distance vector Dx = [Dx(y): y є N ]
• node x:
• • knows cost to each neighbor v: c(x,v)
• • maintains its neighbors’ distance vectors. For each neighbor v, x maintains Dv = [Dv(y): y є N ]

• key idea:

• • from time-to-time, each node sends its own distance vector estimate to neighbors
• • when x receives new DV estimate from neighbor, it updates its own DV using B-F equation:
    $$D_x(y) ← min_v{c(x,v) + D_v(y)} for each node y \in N$$

under minor, natural conditions, the estimate Dx(y) converge to the actual least cost dx(y)

• iterative, asynchronous: each local iteration caused by:
• • local link cost change
• • DV update message from neighbor
• distributed:
• • each node notifies neighbors only when its DV changes
• • neighbors then notify their neighbors if necessary

Distance vector: link cost changes

• link cost changes:
• • node detects local link cost change
• • updates routing info, recalculates distance vector
• • if DV changes, notify neighbors

• “good news travels fast”

t0 : y detects link-cost change, updates its DV, informs its neighbors.

t1 : z receives update from y, updates its table, computes new least cost to x , sends its neighbors its DV.

t2 : y receives z’s update, updates its distance table.  y’s least costs do not change, so y  does not send a message to z.

• bad news travels slow - “count to infinity” problem!
• • 44 iterations before algorithm stabilizes: see text

• poisoned reverse:

• • If Z routes through Y to get to X :
• • Z tells Y its (Z’s) distance to X is infinite (so Y won’t route to X via Z)
• • will this completely solve count to infinity problem?

Comparison of LS and DV algorithms

message complexity

• LS: with n nodes, E links, O(nE) msgs sent
• DV: exchange between neighbors only
• • convergence time varies

speed of convergence

• LS: O(n^2) algorithm requires O(nE) msgs
• • may have oscillations
• DV: convergence time varies
• • may be routing loops
• • count-to-infinity problem

robustness: what happens if router malfunctions?

• LS:
• • node can advertise incorrect link cost
• • each node computes only its own table
• DV:
• • DV node can advertise incorrect path cost
• • each node’s table used by others
• • • error propagate thru network

intra-AS routing in the Internet: OSPF

Making routing scalable

• our routing study thus far - idealized
• • all routers identical
• • network “flat”
• • … not true in practice

• scale: with billions of destinations:

• • can’t store all destinations in routing tables!
• • routing table exchange would swamp links!

• administrative autonomy

• • internet = network of networks
• • each network admin may want to control routing in its own network

Internet approach to scalable routing

aggregate routers into regions known as “autonomous systems” (AS) (a.k.a. “domains”)

• intra-AS routing
• • routing among hosts, routers in same AS (“network”)
• • all routers in AS must run same intra-domain protocol
• • routers in different AS can run different intra-domain routing protocol
• • gateway router: at “edge” of its own AS, has link(s) to router(s) in other AS’es

• inter-AS routing

• • routing among AS’es
• • gateways perform inter-domain routing (as well as intra-domain routing)

Interconnected ASes

• forwarding table configured by both intra- and inter-AS routing algorithm
• • intra-AS routing determine entries for destinations within AS
• • inter-AS & intra-AS determine entries for external destinations

Inter-AS tasks：

• suppose router in AS1 receives datagram destined outside of AS1:

• router should forward packet to gateway router, but which one?

• AS1 must:

• • learn which dests are reachable through AS2, which through AS3
• • propagate this reachability info to all routers in AS1
• • job of inter-AS routing!

Intra-AS Routing:

• also known as interior gateway protocols (IGP)
• most common intra-AS routing protocols:
• • RIP: Routing Information Protocol
• • OSPF: Open Shortest Path First (IS-IS protocol essentially same as OSPF)
• • IGRP: Interior Gateway Routing Protocol (Cisco proprietary for decades, until 2016)

OSPF (Open Shortest Path First)

• “open”: publicly available
• uses link-state algorithm
• • link state packet dissemination
• • topology map at each node
• • route computation using Dijkstra’s algorithm
• router floods OSPF link-state advertisements to all other routers in entire AS
• • carried in OSPF messages directly over IP (rather than TCP or UDP)
• • link state: for each attached link
• IS-IS routing protocol: nearly identical to OSPF

OSPF “advanced” features:

• security: all OSPF messages authenticated (to prevent malicious intrusion)
• multiple same-cost paths allowed (only one path in RIP)
• for each link, multiple cost metrics for different TOS (e.g., satellite link cost set low for best effort ToS; high for real-time ToS)
• integrated uni- and multi-cast support:
• • Multicast OSPF (MOSPF) uses same topology data base as OSPF
• hierarchical OSPF in large domains.

Hierarchical OSPF:

• two-level hierarchy: local area, backbone.
• • link-state advertisements only in area
• • each nodes has detailed area topology; only know direction (shortest path) to nets in other areas.
• area border routers: “summarize” distances to nets in own area, advertise to other Area Border routers.
• backbone routers: run OSPF routing limited to backbone.
• boundary routers: connect to other AS’es.

routing among the ISPs: BGP

Internet inter-AS routing: BGP

• BGP (Border Gateway Protocol): the de facto inter-domain routing protocol
• • “glue that holds the Internet together”
• BGP provides each AS a means to:
• • eBGP: obtain subnet reachability information from neighboring ASes
• • iBGP: propagate reachability information to all AS-internal routers.
• • determine “good” routes to other networks based on reachability information and policy
• allows subnet to advertise its existence to rest of Internet: “I am here”

eBGP, iBGP connections

BGP basics

• BGP session: two BGP routers (“peers”) exchange BGP messages over semi-permanent TCP connection:
• • advertising paths to different destination network prefixes (BGP is a “path vector” protocol)

• when AS3 gateway router 3a advertises path AS3,X to AS2 gateway router 2c:
• • AS3 promises to AS2 it will forward datagrams towards X

Path attributes and BGP routes

• advertised prefix includes BGP attributes
• • prefix + attributes = “route”
• two important attributes:
• • AS-PATH: list of ASes through which prefix advertisement has passed
• • NEXT-HOP: indicates specific internal-AS router to next-hop AS
• Policy-based routing:
• • gateway receiving route advertisement uses import policy to accept/decline path (e.g., never route through AS Y).
• • AS policy also determines whether to advertise path to other neighboring ASes

BGP path advertisement

• AS2 router 2c receives path advertisement AS3,X (via eBGP) from AS3 router 3a
• Based on AS2 policy, AS2 router 2c accepts path AS3,X, propagates (via iBGP) to all AS2 routers
• Based on AS2 policy, AS2 router 2a advertises (via eBGP) path AS2, AS3, X to AS1 router 1c

• gateway router may learn about multiple paths to destination:
• AS1 gateway router 1c learns path AS2,AS3,X from 2a
• AS1 gateway router 1c learns path AS3,X from 3a
• Based on policy, AS1 gateway router 1c chooses path AS3,X, and advertises path within AS1 via iBGP

BGP messages

BGP messages exchanged between peers over TCP connection

BGP messages:

• OPEN: opens TCP connection to remote BGP peer and authenticates sending BGP peer
• UPDATE: advertises new path (or withdraws old)
• KEEPALIVE: keeps connection alive in absence of UPDATES; also ACKs OPEN request
• NOTIFICATION: reports errors in previous msg; also used to close connection

BGP route selection

router may learn about more than one route to destination AS, selects route based on:

1. local preference value attribute: policy decision

2. shortest AS-PATH

3. closest NEXT-HOP router: hot potato routing

4. additional criteria

Hot Potato Routing

• 2d learns (via iBGP) it can route to X via 2a or 2c
• hot potato routing: choose local gateway that has least intra-domain cost (e.g., 2d chooses 2a, even though more AS hops to X): don’t worry about inter-domain cost!

BGP: achieving policy via advertisements

• A advertises path A w to B and to C
• B chooses not to advertise BAw to C:
• • B gets no “revenue” for routing CBAw, since none of C, A, w are B’s customers
• • C does not learn about CBAw path

• C will route CAw (not using B) to get to w

• A,B,C are provider networks

• X,W,Y are customer (of provider networks)
• X is dual-homed: attached to two networks
• policy to enforce: X does not want to route from B to C via X
• • .. so X will not advertise to B a route to C

Why different Intra-, Inter-AS routing ?

• policy:
• • inter-AS: admin wants control over how its traffic routed, who routes through its net.
• • intra-AS: single admin, so no policy decisions needed
• scale:
• • hierarchical routing saves table size, reduced update traffic
• performance:
• • intra-AS: can focus on performance
• • inter-AS: policy may dominate over performance

The SDN control plane

Software defined networking (SDN)

• Internet network layer: historically has been implemented via distributed, per-router approach
• • monolithic router contains switching hardware, runs proprietary implementation of Internet standard protocols (IP, RIP, IS-IS, OSPF, BGP) in proprietary router OS (e.g., Cisco IOS)
• • different “middleboxes” for different network layer functions: firewalls, load balancers, NAT boxes, ..

~2005: renewed interest in rethinking network control plane

Why a logically centralized control plane?

• easier network management: avoid router misconfigurations, greater flexibility of traffic flows
• table-based forwarding (recall OpenFlow API) allows “programming” routers
• • centralized “programming” easier: compute tables centrally and distribute
• • distributed “programming: more difficult: compute tables as result of distributed algorithm (protocol) implemented in each and every router
• open (non-proprietary) implementation of control plane

Traffic engineering: difficult traditional routing

Q: what if network operator wants u-to-z traffic to flow along uvwz, x-to-z traffic to flow xwyz?

• A: need to define link weights so traffic routing algorithm computes routes accordingly (or need a new routing algorithm)!

Link weights are only control “knobs”: wrong!

Q: what if network operator wants to split u-to-z traffic along uvwz and uxyz (load balancing)?

• A: can’t do it (or need a new routing algorithm)

Q: what if w wants to route blue and red traffic differently?

• A: can’t do it (with destination based forwarding, and LS, DV routing)

SDN perspective

Data plane switches

• fast, simple, commodity switches implementing generalized data-plane forwarding in hardware
• switch flow table computed, installed by controller
• API for table-based switch control (e.g., OpenFlow)
• • defines what is controllable and what is not
• protocol for communicating with controller (e.g., OpenFlow)

SDN controller (network OS):

• maintain network state information
• interacts with network control applications “above” via northbound API
• interacts with network switches “below” via southbound API
• implemented as distributed system for performance, scalability, fault-tolerance, robustness

network-control apps:

• “brains” of control: implement control functions using lower-level services, API provided by SND controller
• unbundled: can be provided by 3rd party: distinct from routing vendor, or SDN controller

Components of SDN controller

OpenFlow protocol

• operates between controller, switch
• TCP used to exchange messages
• • optional encryption
• three classes of OpenFlow messages:
• • controller-to-switch
• • asynchronous (switch to controller)
• • symmetric (misc)

controller-to-switch messages:

• Key controller-to-switch messages
• features: controller queries switch features, switch replies
• configure: controller queries/sets switch configuration parameters
• modify-state: add, delete, modify flow entries in the OpenFlow tables
• packet-out: controller can send this packet out of specific switch port
• packet-in: transfer packet (and its control) to controller. See packet-out message from controller
• flow-removed: flow table entry deleted at switch
• port status: inform controller of a change on a port.

Fortunately, network operators don’t “program” switches by creating/sending OpenFlow messages directly. Instead use higher-level abstraction at controller

control/data plane interaction example

1. S1, experiencing link failure using OpenFlow port status message to notify controller

2. SDN controller receives OpenFlow message, updates link status info

3. Dijkstra’s routing algorithm application has previously registered to be called when ever link status changes. It is called.

4. Dijkstra’s routing algorithm access network graph info, link state info in controller, computes new routes

5. link state routing app interacts with flow-table-computation component in SDN controller, which computes new flow tables needed

6. Controller uses OpenFlow to install new tables in switches that need updating

OpenDaylight (ODL) controller

• ODL Lithium controller
• network apps may be contained within, or be external to SDN controller
• Service Abstraction Layer: interconnects internal, external applications and services

ONOS controller

• control apps separate from controller
• intent framework: high-level specification of service: what rather than how
• considerable emphasis on distributed core: service reliability, replication performance scaling

SDN: selected challenges

• hardening the control plane: dependable, reliable, performance-scalable, secure distributed system
• • robustness to failures: leverage strong theory of reliable distributed system for control plane
• • dependability, security: “baked in” from day one?
• networks, protocols meeting mission-specific requirements
• • e.g., real-time, ultra-reliable, ultra-secure
• Internet-scaling

ICMP: The Internet Control Message Protocol

• used by hosts & routers to communicate network-level information
• • error reporting: unreachable host, network, port, protocol
• • echo request/reply (used by ping)
• network-layer “above” IP:
• • ICMP msgs carried in IP datagrams
• ICMP message: type, code plus first 8 bytes of IP datagram causing error

Traceroute and ICMP

• source sends series of UDP segments to destination
• • first set has TTL =1
• • second set has TTL=2, etc.
• • unlikely port number
• when datagram in nth set arrives to nth router:
• • router discards datagram and sends source ICMP message (type 11, code 0)(TTL expired)
• • ICMP message include name of router & IP address
• when ICMP message arrives, source records RTTs

stopping criteria:

• UDP segment eventually arrives at destination host
• destination returns ICMP “port unreachable” message (type 3, code 3)
• source stops

Network management and SNMP

What is network management?

• autonomous systems (aka “network”): 1000s of interacting hardware/software components
• other complex systems requiring monitoring, control:
• • jet airplane
• • nuclear power plant
• • others?

“Network management includes the deployment, integration
and coordination of the hardware, software, and human
elements to monitor, test, poll, configure, analyze, evaluate,
and control the network and element resources to meet the
real-time, operational performance, and Quality of Service
requirements at a reasonable cost.”

Infrastructure for network management

managed devices contain managed objects whose data is gathered into a Management Information Base (MIB)

SNMP protocol: simple network management protocol

Two ways to convey MIB info, commands:

SNMP protocol: message types

SNMP protocol: message formats

SNMP_message_format.png